Распределенная база (РИБ) – часто используемый вариант работы.
Пример – розничная сеть магазинов. Из центральной базы в магазины передаются товары, штрихкоды, цены. Обратно – продажи за смену.
И в таких базах также могут использоваться расширения. А с ними возникают нюансы…
Проблема с распространением расширений в распределенных информационных базах
До выпуска 8.3.12 на уровне платформы не было обмена расширениями в РИБ.
Поэтому, если в центральной базе мы добавили расширение – нужно было еще распространить его во все периферийные узлы.
Для этого приходилось изобретать свои решения, например, веб-серверы во всех магазинах, обмен через веб-сервисы и т.п.
Что изменилось в 8.3.12?
В редакции 8.3.12 обмен расширениями в территориально распределенных базах реализован на уровне платформы.
Теперь не нужны доработки по синхронизации самих расширений, можно не использовать дополнительное ПО, типа веб-серверов.
А когда в типовых конфигурациях появится новый режим совместимости, использование данного функционала станет еще проще – не нужно будет для его реализации устанавливать режим совместимости вручную.
Видео – как передать расширения в периферийные узлы распределенной базы начиная с версии платформы 8.3.12
Мы подготовили для вас 10-минутное видео. Посмотрев его, вы узнаете:
- Как настроить план обмена, чтобы платформа самостоятельно передавала расширения в подчиненные узлы РИБ
- Какие свойства у расширения нужно задать
- Какие данные при этом выгружаются в файл обмена
- Как происходит процесс обмена расширениями через файл
- Какие ограничения существуют у расширений в периферийном узле.
Для тех, кто хочет идти в ногу со временем
Разработка расширений – центральное направление, в котором 1С развивает платформу. И если начать изучение новых технологий уже сейчас, это даст вам явные преимущества :)
Наш курс поможет освоить все возможности расширений буквально за пару месяцев.
Более того – его можно купить в рассрочку (оплатить по частям), в том числе без лишних процентов.
Добрый день!
Если расширения были во всех филиалах и на сервере то же и теперь на сервер включить в режим обмена расширениями. что произойдет с расширениями в филиалах?
Добрый день!
Будет конфликт.
Нужно в периферийных базах удалить расширение, в центральной – включить обмен для расширения. Тогда оно придет в периферийные базы вместе с сообщением обмена.
Добрый день! Вопрос немного не по теме, но все же близок.
Подскажите, возможно ли настроить автоматическую синхронизацию между базами с разными конфигурациями (не РИБ) с использованием своего плана обмена созданного в расширении?
Путем проб и ошибок подозреваю, что это все-таки не возможно, но хочется знать наверняка, может быть что-то не так делаю…
Также еще интересует вопрос: возможна ли синхронизация между объектами, если в приемнике этот объект находится в расширении?
Может быть есть у вас в копилке какие-либо курсы или статьи по теме создания планов обмена в расширениях и настройки такой синхронизации?
Добрый день!
Вообще в расширении можно создать план обмена.
Но нужно учитывать влияние режима совместимости конфигурации. Может быть, что платформа поддерживает такую возможность, а режим совместимости в конкретной конфигурации не позволяет этого сделать.
Так что лучшая рекомендация – протестировать на копии реальной базы. Обращать внимание, можно ли создать план обмена в расширении в этой базе, какие объекты нужно регистрировать (собственные в расширении или заимствованные), нужно ли использовать типовую обработку “Регистрация изменений для обмена данными” с таким планом обмена, можно ли создать в расширении регламентное задание, которое будет выгружать данные, и т.д. То есть проверить все Ваши сценарии работы.
Отдельных статей на тему создания планов обмена в расширениях не делали.
>>возможна ли синхронизация между объектами, если в приемнике этот объект находится в расширении?
Да, возможна.
Хорошо, спасибо за информацию
Добрый день. Очень странная проблема, имеется РИБ Розница 2.3. Изменял расширения, и они прекрасно перемещались в переферийки. Но с определенного момента что-то случилось (причем непонятно вообще что), половина узлов приняла изменения в расширении, половина отказалась, с ошибкой – “Конфигурация расширения не соответствует ожидаемой”. При этом само расширение не отправляется! Выгрузил расширение в файл, загрузил в центральном узле, оно ушло как обновление основной конфигурации, при этом в автоматическом режиме отказалось ставится, потому что внимание при чтении файла обмена “Конфигурация расширения не соответствует ожидаемой”. Смотрел файлы обмена, там расширения отправляются просто с контрольной суммой и со свойствами, но данных самого расширения нет.
Вопрос, как можно зарегистрировать расширение на узле плана обмена? Это вообще возможно?)
Пришлось везде отвязывать узлы и загружать расширение ручками, снова привязывать и только после этого все заработало… Думал может быть дело в открытом конфигураторе (с какой то версии платформы 1С прекрасно даёт открытым держать расширение и обмен работает при этом). В-общем не регистрирует изменения, и вообще непонятно отчего и почему((
Платформа 8.3.19.1264 розница 2.3.10.61.
Думал может дело в релизе, и “патчах”, но нет, как понял из вашего видео расширение отправляется платформой…
Добрый день!
Вручную зарегистрировать расширение на узле плана обмена нельзя. Эти действия выполняются только платформой. Поскольку в файле обмена есть контрольная сумма, то могу предположить, что она используется для определения факта изменения конфигурации.
Прием с отвязыванием от РИБ – единственный, который я знаю для исправления ошибки Конфигурация не соответствует ожидаемой. Так что Вы правильно сделали.
Подобная ошибка периодически встречалась в РИБ еще до появления расширений. Внезапно файл обмена не загружался в периферийную базу, возникала ошибка Конфигурация не соответствует ожидаемой. Приходилось отвязывать базу от РИБ, загружать конфигурацию из центральной базы, снова подключать к РИБ, после этого обмен восстанавливался. Аналогичная ситуация возникает теперь и для расширений, передающихся в РИБ. Это проблема на уровне платформы.
Если есть возможность, напишите разработчикам платформы, пусть проанализируют файл обмена, сами конфигурации баз. Эта проблема мешает выполнению обменов при использовании РИБ, поэтому жду, чтобы в платформу внесли изменения, устраняющие причину такого поведения.
Добрый день, спасибо за ответ!
В итоге проблему я решил, как оказалось, я изменял команду в заимствованном справочнике. И при этом изменении 1С изменения расширения не региструет! Добавил пару пробелов в другом модуле (уже объекта), и вуаля, изменения зарегистрировались (причем вместе с моей командой). Также 1С теперь пересылает не все расширение, а только изменения (раньше отправляла все расширение целиком при изменениях). Надеюсь поможет кому-нибудь))
Спасибо! Интересные наблюдения!
Доброго, толи лыжи не едут. Суть вопроса такова. Есть расширение меняющее метаданные. Оно нормально гуляет из ЦУ в ПУ. Но данные из расширения при этом не синхронизируются. Конфа УНФ. Версии платформы от 18 до 20й. Подскажите куда копать плиз.
Добрый день!
Проверьте состав плана обмена, т.к. в состав заимствованного плана обмена можно включать объекты, созданные в расширении.
На копии баз можно попробовать повысить режим совместимости конфигурации и после этого протестировать обмен.
Или еще вариант – создать отдельный план обмена в расширении для обмена объектами, созданными в расширении.
Доброго, спасибо большое за ответ, он подвиг меня на последующие эксперименты.
1. Да заимствовал план обмена и включал в него свой справочник документ и регистр. синхронизация не шла документы не перетекали.
2. Повысил режим и для расширения и сняв с поддержки и для конфигурации – ноль результата
3. С ланом обмена в расширении не все так просто, как казалось с первого раза, ну и хотелось конечно чтоб стандартно все синхронизировалось.
В итоге все оказалось до банального просто. так как план синхронизации заимствованный из УНФ не совсем стандартный, то как выяснилось путем бесчисленных попыток синхронизаций в отладке , дело было в том что мои документы и справочники не имели префикс базы данных, после прикручивания в расширение префикса стандартная синхронизация УНФ худо бедно пошла, пару раз сломав базу на принимающей стороне.
Еще раз спасибо за ответ.
Спасибо за описание Вашего опыта!
Но осталось непонятным, почему префикс оказывает такое влияние, что именно мешает выгрузке – это особенность платформы, БСП, самой конфигурации или вообще дело в доработках? Или не происходила регистрация изменения справочников/документах на узле плана обмена?
Доброго, Я думаю вопрос именно в поставке УНФ. Стандартная обраточка унф все также не показывает регистрации изменений, но документы туда сюда ходят, скорее всего потомучто я регистрировал автоматом, а не через подписки
Добрый день. Подскажите, обязательно ли устанавливать одинаковые платформы на главном и принимающем узлах для базы РИБ , содержащей расширения?
Добрый день!
Считаю, что это крайне рекомендуется. Еще до того, как появилась возможность передавать расширения в файлах обмена, в РИБ, где используются разные версии платформы, периодически возникала ошибка Конфигурация узла распределенной ИБ не соответствует ожидаемой. Конечно, однозначного подтверждения, что дело именно в разных релизах платформы, у меня нет. Но есть такое предположение.
Поэтому в РИБ использую одинаковые релизы платформы на всех узлах.
Приветствую! Подскажите, как выгрузить образ ПУСТОЙ базы без данных. При выгрузке в базу нового магазина попадают все документы других магазинов. И ККМ тоже, хотя не должно так быть. Что делаю не так?
Добрый день!
В видео на данной странице мы говорим совсем про другое – про передачу расширений в РИБ.
Предполагаю, что для решения Вашей задачи нужно настраивать фильтры при создании нового узла РИБ.
Здравствуйте! очень помогла Ваша статья. Хотел задать вопрос: если образ РИБ был создан ДО того как поставили галочку об использовании расширений в Плане обмена то не надо создавать образ заново?
Добрый день!
Нет, образ заново создавать не нужно.
Добрый вечер. Подскажите, пожалуйста, есть ли возможность использовать расширение только в подчиненном узле. Спасибо
Добрый день!
Да, в таком случае нужно добавить расширение непосредственно в подчиненном узле, не устанавливать для него галочку Используется в распределенной информационной базе. Тогда такое расширение не будет мигрировать в другие узлы РИБ.
Здравствуйте, имеем РИБ.
На ЦБ УТ 11.4.11.63 типовая не снятая, добавлено два расширения с дополнением реквизитов основной конфигурации (документы, справочники, перечисления, обработки), но эти новые объекты не включены в планы обмена, как и нет в расширении плана обмена “сОтборами”. В типовом плане обмена “сОтборами” так же НЕ установлена галочка “Включать расширения конфигурации”.
В настройках расширений стоят галочки “Используется в распределенной ИБ”.
Создаем новый узел обмена с отбором (по подразделениям, организациям,складам, видам цен)
при формировании начального образа выдает ошибку:
“Не удалось создать начальный образ по причине: В текущем сеансе существуют изменяющие данные расширения конфигурации, неиспользуемые в распределенной информационной базе.
{ОбщаяФорма.СозданиеНачальногоОбразаСФайлами.Форма(392)}: ВызватьИсключение НСтр(“ru = ‘Не удалось создать начальный образ по причине:'”) + ” ” + Результат.КраткоеПредставлениеОшибки; ”
Хотелось бы:
1. Не переносить расширения конфигурации на узлы, так как они нужны только в ЦБ даже с новыми объектами и модифицированными типовыми. Это получится?
2. Не хотелось бы снимать с поддержки УТ.
3. Что делать? :)
Добрый день!
Да, есть такая проблема.
Глобально причина в том, что типовая конфигурация отстает от новых механизмов платформы. Например, режим совместимости в УТ 11 используется еще только Версия 8.3.12.
Я не нашел никаких планов разработчиков, когда они планируют установить галочку Включать расширения конфигурации для планов обмена (РИБ).
Поэтому можно включить возможность изменения для плана обмена (снять с замка), установить свойство Включать расширения конфигурации.
Второй вариант – вместо РИБ использовать обмен по правилам либо другую альтернативу (выгрузка в файл, обмен через собственный веб-сервис и т.д.). Тут могут потребоваться доработки, возможно значительные.
И третий вариант – перенести доработки, изменяющие структуру данных, в основную конфигурацию.
В итоге так и сделал. Снял с поддержки УТ. Снял с поддержки ПланОбмена.СОтборами, в нем установил галочку “Включать расширения конфигурации”, сохранил. Сформировал узел, выгрузилось, настроил узел на обмен всё пошло. Спасибо, будем ждать галочки в обновлениях или контролировать её самому.
Хотя счастье длилось не долго! :)
Все было хорошо, обмен РБД по данных основной конфигурации шел хорошо и стабильно, пока не появилась необходимость внести изменения в ЦБ расширения. Добавил пару объектов в расширение и обмен РБД встал. При нажатии синхронизации в ЦБ пишет:
——————————————
Ошибка чтения файла сообщения обмена: Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел.
{Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта( …. . .. . ….. );
по причине:
Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел.
———————————————————————————-
Тут я поторопился, решил выгрузить расширения из ЦБ и загрузить в узел, но как вы уже успели догадаться это не возможно, так как конфигурация узла закрыта для изменений в том числе расширений. Т.е. нельзя загрузить расширения в узел.
Выполнять танцы с бубном по снятию признака узла бд, после обновить расширения, а затем вернуть признак узла, это крайне не удобно так как периодичность внесения изменений в ЦБ расширения будет огромная.
Т.е. тут нужно сразу понять, что сообщение об ошибках обмена началось ещё со стороны ЦБ в момент синхронизации с узлом. Очевидно это та самая ошибка по контрольной сумме версий конфигурации, из-за чего становиться физически очень сложный обмен РБД при наличии расширений конфигурации и дальнейших их модификаций. Причем и при не желании переносить расширения ЦБ в узлы, нам это приходится всё равно делать этот перенос с изменением и снятием с поддержки конфигурации ЦБ и установкой в план обмена переноса расширений, так и при наличии принудительного обмена расширениями они фактически не могут мигрировать между конфигурациями ЦБ и узла, так как появляется расхождение контрольной суммы. Фатальная ситуация.
Подскажите пожалуйста, чего ждать и как быть. :)
В таком случае нужно продумывать альтернативные варианты, раз такая схема приводит к ошибкам.
Например, отказаться от РИБ, выполнять обмен по правилам. Либо перенести доработки в основную конфигурацию, оставить в расширениях только доработки, не изменяющие структуру хранения данных (например, программный код). Смотрите, что проще и быстрее с точки зрения реализации.
И по-хорошему – отправить на v8@1c.ru описание ошибки, чтобы разработчики платформы могли исправить ошибку с контрольной суммой конфигурации.
Стал курить, читать и мельком наткнулся на сообщения коллег о разности поведения механизмов обмена между нажатием кнопки “Синхронизировать” и “Выполнить сценарий”.
Удалил файлы обмена старые, нажал “Выполнить сценарий” в ЦБ – всё выгрузилось, т.е. модифицированное расширение выгрузилось в файл обмена для узла, и на узле уже с надеждой жал кнопку “Выполнить сценарий” вместо “Синхронизация” и загрузилось и по журналу регистрации было написано перезагрузить базу (узла) для принятия расширений, перегрузил, ещё раз запустил, опять кнопку “Выполнить сценарий” и всё, он прошел удачно!!!! Модифицированные расширения из ЦБ загрузились в узел только по кнопке “Выполнить сценарий”.
Интересное наблюдение!
Остается только вопрос, почему появляются расхождения в контрольной сумме в файле выгрузки? Это действие выполняется на уровне платформы, вмешаться в это поведение мы не можем.
Нельзя создать в расширении изменяющие данные (Справочник, документы и т.п.) – и не отправлять это в РИБ.
При создании начального образа периферийной базы, который поддерживает передачу расширений конфигурации, в него переносятся все расширения, которые подключены с установленным флагом Используется в распределенной информационной базе. Создание начального образа будет невозможно, если в сеансе, из которого выполняется создание начального образа:
● Существуют неподключенные расширения с флагом Используется в распределенной информационной базе.
● Существуют расширения, изменяющие данные, для которых установлен флаг Используется в распределенной информационной базе и которые не являются активными.
● Существуют расширения, изменяющие данные, для которых не установлен флаг Используется в распределенной информационной базе.
● Существуют расширения с флагом Используется в распределенной информационной базе, для которых загружены новые версии расширений.
В момент формирования сообщения обмена на сеанс, из которого выполняется формирование, накладываются те же требования, что и при формировании начального образа.
https://its.1c.ru/db/v8315doc#bookmark:dev:TI000001990
Да, конфигурации баз во всех узлах РИБ должна быть полностью одинаковой.
Добрый день,
А если в центральном узле в расширение добавить новый справочник. Элементы этого справочника, созданные в режиме “предприятие” будут автоматически переносится во все узлы (магазины) или в расширении нужно будет заимствовать план обмена (например, РИБ по магазинам для розницы), в котором указывать параметры авторегистрации “разрешить” для нового справочника?
Добрый день!
Нет, с помощью этого механизма в периферийные узлы переносятся только сами расширения.
Чтобы обеспечить перенос данных, нужно настраивать планы обмена.
А возможно ли в итоге обмениваться данными из расширений (например, данными нового справочника) с узлами РИБ не дорабатывая при этом конфигурацию (пользуясь только расширениями)?
Да. Например, можно реализовать правила в Конвертации данных или создать свою собственную обработку для переноса данных нового справочника.
Вы слишком сложный путь предлагаете. Я проверил, достаточно в расширении позаимствовать план обмена (например, риб по магазину) и в нем для добавленных справочников включить авторегистрацию. Тогда этот справочник будет передаваться в узлы. Да и в типовых документах, где используется ссылка на справочник из расширения всё будет перегружаться и работать.
Я понял, что вообще без доработок надо обойтись, внешними средствами:)
А так да, всё правильно – при помощи расширений можно работать с планами обмена.
Не подскажете, почему даже в последней версии конфигурации “Бухгалтерия предприятия 3.0”, например, версии 3.0.68.58, в плане обмена РИБ (“Полный”, “ПоОрганизации”) не установлены галочки “Включать расширения конфигурации”, хотя режим совместимости у конфигурации уже давно 8.3.12? Понятно, что вопрос нужно адресовать разработчикам прикладного решения “Бухгалтерия предприятия 3.0”, но надеюсь на вашу осведомленность.
При установке галочки “Включать расширения конфигурации” у плана обмена РИБ “ПоОрганизации” в конфигурации “Бухгалтерия предприятия 3.0” версии 3.0.68.58, и последующей попытки синхронизации, последняя не проходит с сообщением:
“ПланСчетов.Хозрасчетный. Недопустимо использование предопределенных элементов, если не включены все разделители объекта конфигурации”.
Если использовать расширения, изменяющие структуру метаданных конфигурации, в которой нет галочки “Включать расширения конфигурации” (БП 3.0), тогда при синхронизации ловим ошибку:
“Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел.”
При этом все расширения, само собой, перенесены в РИБ вручную.
Манипуляции с контрольными суммами в файлах обмена помогают провести обмен, но лишь до следующего обмена данными, ведь каждый раз вручную менять контрольные суммы не вариант.
В итоге не могу заставить нормально работать “Бухгалтерия предприятия 3.0” версии 3.0.68.58,
совместно с расширениями, меняющими структуру метаданных конфигурации, т.к. при обмене с РИБ “ПоОрганизации” получаю:
“Данные принимаются от узла с другим набором расширений, меняющих структуру данных. Необходимо произвести перенос расширений конфигурации в узел.”
При этом все расширения, само собой, перенесены в РИБ вручную.
У кого-нибудь такая связка расширений и РИБ работает?
Добрый день!
Можно попробовать выполнить обмены (или вообще все действия, начиная с формирования периферийных узлов) на разных релизах платформы. Потому что контрольные суммы формируются в файлах обмена на уровне платформы, это не механизм прикладного решения, редактированием кода на встроенном языке тут не обойтись. Возможно, в каком-нибудь релизе платформы дорабатывали/изменяли этот (или смежный?) механизм, что привело к возникновению подобных ошибок.
То, что контрольные суммы отличаются, – это некорректное поведение. По возможности задайте этот вопрос разработчикам платформы на v8@1c.ru, отправьте базы с примером воспроизведения, чтобы разработчики смогли диагностировать причину такого поведения платформы.
Добрый день. Создал первоначальный образ полностью по вашей методике. При первой выгрузке из центральной базы во вновь созданный образ, я получаю ошибку принятия сообщения. А именно:
“Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел.”
Как можно решить эту задачу?
Буду очень признателен за любую информацию
Добрый день!
Такая ошибка может возникать, даже когда в базе нет ни одного расширения.
Система считает, что в главном и в периферийном узле разные конфигурации. В файлах обмена есть специальная контрольная сумма (тег Digest в xml-файле). Она не совпадает, поэтому система считает, что обмениваются вообще разные базы, не дает загружать данные.
Раньше, когда расширений еще не было, лечилось полной загрузкой конфигурации из cf-файла. Тогда конфигурации становились на 100% одинаковыми, обмен восстанавливался.
Что можно попробовать сделать.
1) Выполнить обмен на предыдущих релизах платформы (например, 8.3.12). Может, изменялись какие-то внутренние алгоритмы. Один из участников курса обошел проблему, выполнив загрузку на платформе 8.3.12.1714, хотя на релизе 8.3.13.1644 возникала указанная Вами ошибка.
2) Проверить, что в периферийной базе есть все расширения из центральной, они идентичны, конфигурация базы данных обновлена. Попробовать заново выполнить цикл обмена.
3) Еще пробуют вручную редактировать контрольные суммы в файлах обмена, чтобы восстановился обмен. После этого обмен начинает работать корректно. Обязательно иметь копии баз, чтобы было к чему вернуться в случае проблем.
Помогло редактирование контрольных сумм. По крайней мере первый обмен прошел. Спасибо большое
Здравствуйте, хотелось бы воспользоваться возможностью именно НЕ применения расширения в РИБ, а пользоваться им только в центральном узле. Не ставлю признак “Используется в распределенной ИБ” и при попытке создать узел: “Не удалось создать начальный образ по причине: В текущем сеансе существуют изменяющие данные расширения конфигурации, неиспользуемые в распределенной информационной базе.”
Добрый день!
Конфигурация во всех узлах РИБ должна быть идентичной. Поэтому если расширение изменяет структуру конфигурации, то оно должно быть выгружено в узел.
День добрый!
Есть 1С:Предприятие 8.3.12.1616 и Розница 2.2.9.20 с уже работающей РИБ. Сделали расширение тестовое. Как его распространить на удаленные базы? Пробовали создать свой план обмена, но в нем не дает отметить подсистему в которой участвует новый план обмена… Уже существующие планы не дает редактировать (замочки на них).
Дайте подсказку, что мы не так делаем!
Спасибо
Добрый день!
Первым делом нужно проверить режим совместимости конфигурации. Чтобы план обмена умел передавать расширения в сообщениях обмена, режим совместимости должен быть не ниже Версия 8.3.12. Если он ниже, то обмениваться расширениями между базами РИБ нужно будет вручную.
Если режим совместимости 8.3.12 и выше, то в плане обмена нужно установить галочку Включать расширения конфигурации. Тогда обмен расширениями будет выполняться на уровне платформы. Чтобы в типовых конфигурациях можно было вносить исправления, нужно для объекта включить возможность редактирования (“снять с замка”).
Добрый день!
Расширение1 передано в периферийную базу. Сможем ли мы увидеть его в пользовательском режиме, без использования конфигуратора?
Добрый день!
Да, конечно. Расширение, пришедшее из главного узла, как и любое другое, будет видно в пользовательском режиме.
Доброго времени суток!
Хотел бы уточнить по схеме обновления расширений до 8.3.12, веб-сервер нужен только один, в центральной базе, а подчиненные узлы к нему подключаются через веб-сервис.
И вопрос, когда вы добавили Расширение1 и сделали обмен, в показанной XML присутствуют данные от расширения ВесТовара, я правильно понимаю что обмен не разностный, а полный? Т.е. при любых обменах, расширения включаются в сообщение обмена в полном объёме, а не разница? По тому-что я не заметил на видео, чтоб изменилось расширение ВесТовара.
Спасибо!
Добрый день!
1. Да, конечно, в простом случае достаточно веб-сервера в центре. Но если из периферийной базы нужно будет передать расширение дальше “по иерархии” в подчиненную базу следующего уровня, то и в узле тоже потребуется веб-сервер. Или если в торговой точке нужно передавать расширение в подчиненные распределенные базы по кассам. Поэтому на схеме для общего случая оставил картинки веб-сервера.
2. Погонял обмен расширениями на демо-базах. Получилось, что расширения всегда попадали в файл обмена. Даже если совершить полный цикл обмена, т.е. загрузить ответ подчиненной базы обратно в центральную.
Ок! Большое спасибо за ответы! Конечно была надежда на разностные обмены расширения, но так тоже терпимо. Тем-более что зачастую расширения даже большие, весят не много.
Добрый день.
Не подскажете примерный срок перехода на режим совместимости 8.3.11 (12) на типовых. Интересует ERP и БП 3.0
Добрый день!
На пользовательском сайте для БП указана ориентировочная дата выхода – сентябрь 2018 (Адаптация конфигурации к работе на платформе 8.3.12 без совместимости с предыдущими версиями).
Здравствуйте! Я бухгалтер,но часто сталкиваюсь с тем, что нужно подредактировать печатную форму либо создать новую обработку и к ней печатную форму. Мне не нужны абсолютно все знания, можно как-то пройти урезанный курс обучения? Какова стоимость?
Виктория, нельзя приобрести часть занятий курса. Курс не делится на части и приобрести его можно только целиком.
Обратите внимание, до 24 апреля курс можно приобрести по сниженной цене.
Здравствуйте, я покупал несколько курсов.Перед покупкой этого курса прошу ответить на простой вопрос:
Есть процедура общего модуля, в ней запрос. Как я должен оформить расширение конфигурации (кратко), чтоб она в дальнейшем обновлялась без меня. Например, при условии, что 1с внесет изменения в запрос в этой процедуре.
Добрый день!
Можно использовать аннотацию После, в модуле в расширении реализовать логику, как именно следует изменить текст запроса. Например, с использованием функции СтрЗаменить:
Процедура Расш_СформироватьТекстЗапроса(ТекстЗапроса)
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "...", "...");
КонецПроцедуры
Но не всегда порядок написания кода этой процедуры в основной конфигурации дает возможность выполнить доработки таким образом. Например, в общем модуле есть длинная процедура, в ней надо поменять (или добавить) пару строк в середине.
В таком случае придется воспользоваться аннотацией Вместо, перенести весь код процедуры в расширение, откорректировать пару строк.
Обновлять такую процедуру будет неудобно – надо проверять, изменился ли код в типовой конфигурации.
К сожалению сейчас в платформе нет механизма для сравнения/объединения заимствованных в расширение процедур, модулей с основной конфигурацией и конфигурацией поставщика.
На партнерском форуме подобные пожелания высказываются, разработчики платформы их фиксируют. Ждем, что в следующих релизах появятся новые возможности, повышающие удобство работы с расширениями.